1. Field of the Invention
The present invention relates generally to an improved data processing system, and in particular, to a computer implemented method and apparatus for improving data transfer. Still more particularly, the present invention relates to a computer implemented method, apparatus, and computer usable code for improved throughput through a network connection by receiver side congestion window tracking.
2. Description of the Related Art
Many businesses conduct business and transfer data through networks. The Internet is one of the largest networks used for the transfer of information. Users often will request data from Websites. Additionally, businesses will transfer data to other businesses through Internet connections. Additionally, backup services using secure connections over the Internet are becoming more commonplace. The protocol used for many of these data transfers involve the transmission control protocol/Internet Protocol (TCP/IP).
A server application reading data from a TCP socket currently had two ways to obtain the data. One mechanism includes performing a normal receive system call in a socket. A socket is an IP address plus a port number. A port number is assigned to user sessions and server applications in these examples. The other method is to poll the socket for the amount of available data until enough data is present for processing. One example is the Advanced Interactive Executive (AIX®) network file system (NFS) implementation, which polls the socket for availability of data. This type of system delays the acknowledgement of a packet until either data is removed from receive buffer or a time out condition occurs. When a sender lacks acknowledgement packets, the sender eventually stops sending data. In some cases, this occurs before the full amount of data expected by the receiving application has been sent by the sender. This situation is an example of a congestion-avoided system.
This type of system is designed to avoid flooding an already congested network with more data, presuming that this additional data has a low likelihood of making it to the destination. As a result, a behavior occurs in which the sending host starts out sending two times the maximum segment size bytes, then waits until a delayed acknowledgement time out occurs on the remote host, resulting in an acknowledgement packet before sending further data. After a period of time, the “congestion window” grows large enough to encompass the full expected data. Then, this problem disappears.
However, a simple lost packet may result in the resetting of the congestion window (per TCP protocol guidelines). As a result, throughput drops for an extended period of time in this situation. This situation may continue over and over, in which case, the throughput on this TCP session will be very low (poor).
One solution to this problem is to simply have the receiver not delay the acknowledgements. This results in more acknowledgements sent by the receiver and more acknowledgements received by the sender. This increases the processing overhead on both the sender and the receiver (uses more CPU instructions and cycles). If the server has a lot of these TCP connections, then the overhead on the server will be increased.